QUICK-N-DIRTY GUIDE TO MEMORY MANAGEMENT UNDER DOS 5.0 by Dave Eyre 70303,2533 INTRODUCTION With DOS 5.0 you have considerable control over your PC's memory, and can put this memory to much better use than in the past. But though the DOS 5.0 manual gives a good description of each individual memory management feature, it gives no clear picture of how all these features hang together, or how they are best combined for maximum benefit to your PC operations. The book "Managing Memory with with DOS 5" by Dan Gookin gives a good comprehensive treatment, but for the user who is only looking for quick answers the essential points tend to get swamped by excessive detail. I wrote this quick-n-dirty guide to help people who come to me with questions about setting up their DOS 5 CONFIG.SYS file - people who just need enough to get by and don't want a 200-page doctoral dissertation. This guide is designed to give average users a basic grasp of memory management under DOS 5.0 - enough to allow them to design a fairly competent CONFIG.SYS file. To avoid unnecessary confusion it skates lightly over topics which are not relevant to a simple treatment. THE THREE PARTS OF MEMORY As a working example I have chosen a 386 machine with 4 Megabytes of RAM. This 4096 K of RAM is divided up as follows: a) The first 640 K is called "Conventional Memory" and is where you load and operate your "working" software such as word processor, spreadsheet, etc. b) The next 384 K (from 640 K to 1024 K), is called "Upper Memory". This is reserved by DOS for its own use and previously there was no way of tapping into the large reserves of unused memory in this area, but with DOS 5.0 this now becomes possible. c) The remaining 3072 K is called "Extended Memory". PROTECTING THE 640 K CONVENTIONAL MEMORY In memory management, a good first priority is to save as much Conventional Memory as you can for your "working" software (at any rate, that's MY first priority). Unfortunately, during a normal boot-up procedure, DOS grabs several chunks of Conventional Memory for the DEVICES loaded by CONFIG.SYS, plus memory-resident files such as Sidekick or Norton Commander loaded by AUTOEXEC.BAT, plus the DOS operating system itself (which needs quite a bit of memory). So you can be left with something much less than 640 K to work with. In extreme cases (loading too many device drivers and memory-resident programs) the remaining Conventional Memory may not be big enough to run some of your working software. Under DOS 5.0 you can get around this problem by using three tricks: a) On 286 and 386 machines, DOS can be tricked into handling (addressing) an extra 64 K, over the top of its normal 1024 K. This is called the "High Memory Area" (HMA). To get access to this memory you must load HIMEM.SYS as a device in your CONFIG.SYS file. This device must be loaded first, before you do any other messing around with memory allocations. So (preferably) the first line of your CONFIG.SYS file should read: DEVICE=C:\DOS\HIMEM.SYS So now you have 384 + 64 = 448 K in Upper Memory, but this is still reserved by DOS and is not available for use by your working software. DOS actually uses only a smallish fraction of this Upper Memory, and there are large unused sections that could be put to good use if only there were some way of getting at them. The remaining two tricks allow you to do this. b) Put the following command in the CONFIG.SYS file: DOS=HIGH This command forces DOS to load its system into Upper Memory instead of stealing a chunk of Conventional Memory. Instead of occupying about 65 K of Conventional Memory, DOS 5.0 will then occupy about 14 K, saving you an extra 51 K for your "working" software. c) Now modify the CONFIG.SYS file so that the DOS command reads: DOS=HIGH,UMB The UMB stands for Upper Memory Block, and it "alerts" DOS to the fact that you are going to load some of the device drivers or memory-resident programs into Upper Memory instead of having them steal chunks from Conventional Memory. Later on we'll see how to load devices etc. into Upper Memory. STEALING EXPANDED MEMORY FROM EXTENDED MEMORY Remember we started off with 3072 K of Extended Memory, but then we stole 64 K for the High Memory Area. So now we are left with 3008 K of Extended Memory. Before you start loading device drivers or assign memory to different applications, it is first of all necessary to set up the Expanded Memory Manager EMM386.EXE. This can do many things, but its two basic functions are: a) It controls the Upper Memory Blocks (chunks of Upper Memory) where you are going to put your various device drivers and memory-resident programs (to stop them using valuable Conventional Memory). But you can't put these things in Upper Memory without first activating EMM386.EXE, so it's good policy to load this device in the third line of the CONFIG.SYS file, before you proceed to load device drivers. b) It sets up an Expanded Memory System (EMS), which requires a bit of explanation. Although DOS can only access ("address") the first 1024 K of memory, the Expanded Memory Manager (EMM) gives it a boost which allows it (effectively) to access a much greater chunk of memory. In fact, the EMM manager will allow DOS to access any amount of your Extended Memory. You can specify how much memory you require, and then the EMM manager will effectively cut this out of Extended Memory and make it available to DOS as Expanded Memory (or EMS). At the same time, the EMM manager needs to mark out a 64 K section in the Upper Memory, which acts as a kind of "window" through which DOS can "see" or access all the Expanded Memory (read Gookin for more details). Generally speaking, you only need Expanded Memory if you are operating software that needs it and knows how to use it. In such cases the software manual will (or should) give instructions on how the Expanded Memory is to be set up. Otherwise, you don't need Expanded Memory. So there are basically two ways of setting up your EMM manager: DEVICE=C:\DOS\EMM386.EXE NOEMS or: DEVICE=C:\DOS\EMM386.EXE 512 RAM The first option sets up the EMM system to control the Upper Memory Blocks only, with no Expanded Memory. Since there is no Expanded Memory, the EMM manager does not need to mark out the 64 K "window" mentioned above, so this 64 K is FREE in Upper Memory and can be used for loading device drivers and memory-resident programs. This is the best option when your normal software operations don't need Expanded Memory. The second option sets up an Expanded Memory of 512 K (or whatever you specify) and the RAM option means that it also controls the Upper Memory Blocks. With this option the EMM manager marks out the 64 K of "window" in Upper Memory. This means that there's less space in Upper Memory to load device drivers and memory-resident programs. This is the best option when your working software needs Expanded Memory, and the size of the Expanded Memory System (EMS) must be tailored to the needs of the software. At this stage the CONFIG.SYS file contains only three lines, as follows: DEVICE=C:\DOS\HIMEM.SYS DOS=HIGH,UMB DEVICE=C:\DOS\EMM386.EXE NOEMS It's useful to boot up with this CONFIG.SYS file, then look at its effect on memory by running one or other of the following commands: mem /c |more (to view memory details on screen) mem /c >prn (to print memory details) You will probably find that you have started out with 3145728 bytes (3072 K) of Extended Memory, but now have only 2907136 bytes (2839 K). The High Memory Area stole 64 K (remember?), and now the EMM manager has stolen another 169 K, even though we've not allocated any Expanded Memory. The important point is that, after the first three lines of the CONFIG.SYS file, we have clipped 233 K off Extended Memory and are left with 2839 K (of course, this will vary from one system to another). MAKING BEST USE OF THE REMAINING EXTENDED MEMORY The three most common ways of using Extended Memory are: a) Use part of it for programs which need it. Windows, for instance, makes good use of Extended Memory. b) Use part of it for SMARTDRV Disk Cache. The Disk Cache gives a remarkable speeding up of disk operations, and it is generally desirable to install SMARTDRV with at least its default size of 256 K. SMARTDRV takes over many of the functions of the BUFFER system and FASTOPEN, so if SMARTDRV is installed the BUFFERS can be set to some low value (say 3) and FASTOPEN can be ignored. c) Use part of it for RAMDRIVE. This means that a specified part of Extended Memory is set aside for use as a Virtual Disk - actually a large chunk of RAM which mimics the behaviour of a conventional disk. The main advantage is that the Virtual Disk operates much faster than a hardware disk. The main disadvantage is that, when the computer is switched off (or there is a power failure), the contents of this disk will be lost. Virtual Disk operations are nevertheless popular because of their speed, and usually have to be controlled through a batch file which transfers the necessary files from hard disk to virtual disk, then, after work has been done on the files, transfers them back to hard disk in their modified form. Such operations may require a better- than-average understanding of DOS on the part of the user. There is no carved-in-stone rule for dividing Extended Memory among the above three options; it varies according to individual use and preference. A good strategy is to have a series of CONFIG.SYS files, each tailored to give the best memory usage for its particular application. Then, after boot-up, the appropriate CONFIG.SYS file is chosen and activated by re-booting. LOADING DEVICE DRIVERS INTO UPPER MEMORY The following is a fairly typical CONFIG.SYS listing: DEVICE=C:\DOS\HIMEM.SYS DOS=HIGH,UMB DEVICE=C:\DOS\EMM386.EXE NOEMS DEVICE=C:\DOS\ANSI.SYS DEVICE=C:\MOUSE\MOUSE.SYS DEVICE=C:\DOS\SMARTDRV.SYS 1024 DEVICE=C:\DOS\RAMDRIVE.SYS 1814 512 64 /E BUFFERS=3 FILES=30 BREAK=ON SHELL=C:\COMMAND.COM /E:1024 /P Note that the memories assigned to SMARTDRV and RAMDRIVE total 2838 K, which in my working example will leave 1 K (1024 bytes) of unused Extended Memory. As a first step in assigning device drivers to the Upper Memory, boot with the above version of CONFIG.SYS (using whatever variations you like) and then run the command "mem /c |more" (or "mem /c >prn") to look at the memory usage. First of all, you'll find that all the device drivers (ANSI, MOUSE, SMARTDRV, RAMDRIVE) have been loaded into Conventional Memory, and "mem" shows the size of each driver. [Note: some people get a bit confused here. Take SMARTDRV for example: the DRIVER for SMARTDRV (the bit that controls it) is loaded into Conventional Memory, but the 1024 K required for the Disk Cache is located in Extended Memory]. Also, you will find that Upper Memory has several chunks of FREE memory available, and "mem" shows you the size of each chunk. You now have to look at the sizes of the device drivers and figure out how many of these drivers can be fitted into the FREE parts of Upper Memory. Let's suppose that ANSI, MOUSE and SMARTDRV can be fitted into Upper Memory, but there's not enough space to take RAMDRIVE. It's a simple matter to load ANSI, MOUSE and SMARTDRV into Upper Memory: all you have to do is change DEVICE to DEVICEHIGH in the CONFIG.SYS file, which then reads as follows: DEVICE=C:\DOS\HIMEM.SYS DOS=HIGH,UMB DEVICE=C:\DOS\EMM386.EXE NOEMS [can't use DEVICEHIGH here] DEVICEHIGH=C:\DOS\ANSI.SYS DEVICEHIGH=C:\MOUSE\MOUSE.SYS DEVICEHIGH=C:\DOS\SMARTDRV.SYS 1024 DEVICE=C:\DOS\RAMDRIVE.SYS 1814 512 64 /E BUFFERS=3 FILES=30 BREAK=ON SHELL=C:\COMMAND.COM /E:1024 /P The best policy is to try loading one driver at a time into Upper Memory, then reboot with the modified CONFIG.SYS, then use "mem /c |more" to look at the effect on memory. Sometimes you will find that a driver will not load into Upper Memory, even though there seems to be enough FREE memory to take it (read Gookin if you want an explanation). LOADING MEMORY-RESIDENT PROGRAMS INTO UPPER MEMORY Memory-resident programs (TSR's) are normally loaded into Conventional Memory by the AUTOEXEC.BAT file at boot-up. The procedure for loading them into Upper Memory is similar to that for device drivers: boot-up in the normal way, then use the "mem" command to list the memory allocations. If a memory-resident program is loaded into Conventional Memory, note its size and also the amount of FREE Upper Memory. If there is enough FREE memory, the program can be made to load into Upper Memory by use of the command "loadhigh". For example, AUTOEXEC.BAT might contain a command line "test", which calls-up a memory-resident program "test.exe". If the command line is changed to "loadhigh test" the program will be loaded into Upper Memory when you re-boot. But a note of caution: some memory-resident programs might cause severe disruption if loaded into Upper Memory, and your PC might abort or go into some other failure mode at boot-up. Therefore when modifying AUTOEXEC.BAT with "loadhigh" commands it is advisable to have a DOS system floppy disk handy, so you can boot-up independently of the hard disk then get into AUTOEXEC.BAT and remove the offending command. LOOKING DEEPER This quick-n-dirty guide is only a superficial treatment designed to get typical users off the ground. If you have understood most of it then you will be able to return to the DOS 5.0 Manual and read it with a better understanding. Personally, I found that the Manual leaves a lot of questions unanswered, so I turned to "Managing Memory with with DOS 5" by Dan Gookin (published by Microsoft). This gave me most of the answers I was looking for, and in my opinion will amply reward those who are prepared to put a bit of effort into reading it. ----------------end-of-author's-documentation--------------- Software Library Information: This disk copy provided as a service of Public (software) Library We are not the authors of this program, nor are we associated with the author in any way other than as a distributor of the program in accordance with the author's terms of distribution. Please direct shareware payments and specific questions about this program to the author of the program, whose name appears elsewhere in this documentation. If you have trouble getting in touch with the author, we will do whatever we can to help you with your questions. All programs have been tested and do run. To report problems, please use the form that is in the file PROBLEM.DOC on many of our disks or in other written for- mat with screen printouts, if possible. PsL cannot debug pro- programs over the telephone, though we can answer questions. Disks in the PsL are updated monthly, so if you did not get this disk directly from the PsL, you should be aware that the files in this set may no longer be the current versions. Also, if you got this disk from another vendor and are having prob- lems, be aware that some files may have become corrupted or lost by that vendor. Get a current, working disk from PsL. For a copy of the latest monthly software library newsletter and a list of the 3,000+ disks in the library, call or write Public (software) Library P.O.Box 35705 - F Houston, TX 77235-5705 Orders only: 1-800-2424-PSL MC/Visa/AmEx/Discover Outside of U.S. or in Texas or for general information, Call 1-713-524-6394 PsL also has an outstanding catalog for the Macintosh.